@andycochran @ncoden @kball does this look OK to you?
Makes sense to me.

Well... /settings/settings.scss is automatically generated by the gulp deploy:settings task. Because of deploy is based on build, we cannot use /settings/settings.scss in build:sass.

I think /settings/settings.scss is intended to be copied by the user for its own sass project. I agree the file paht and name is not clear about this purpose.

Hmm... I think this may not play nicely with setting things up in an app or other location, where we typically have you include settings and then the items you want to include... letting you move settings to wherever you want in your own app structure without mucking with the library code itself... Not saying that is the ideal setup, but I think this seemingly small change would actually have cascading impacts on existing sites and apps

I wasn't sure about the impact of this change, so I put a questionmark at the end of this PR. The docs are pretty clear about how to use the _settings.scss:

http://foundation.zurb.com/sites/docs/sass.html

I can see @kball's point. If a user has included a mysettings.scss its values would be overriden by a following _settings.scss.

If you want, we could put something like this in foundation.scss:

// Settings
// import your own `settings` here or 
// import and modify the default settings through
// @import "settings/settings";

If you want to leave everything as is, I am happy for this PR to be closed.